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Abstract 
This document examines a wide range of conferencing requirements for 
tightly coupled SIP conferences. Separate documents will map the 
requirements to existing protocol primitives, define new protocol 
extensions, and introduce new protocols as needed. Together, these 
documents will provide a guide for building interoperable SIP 


conferencing applications. 
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1. Introduction 


This document examines a wide range of conferencing requirements for 
tightly coupled SIP (RFC 3261 [2]) conferencing. 


The requirements are grouped by subjects in various areas allowing 
solutions to progress in parallel. 


Separate documents will map the requirements to existing protocol 
primitives, define new protocol extensions, and introduce new 
protocols as needed. 


Together, these documents will provide a guide for building 
interoperable SIP conferencing applications. 


The terms "MAY", "SHOULD", and "MUST" are to be interpreted as 
described in RFC 2119 [1]. 


2. An Overview 


A SIP conference is an association of SIP user agents (i.e., 
conference participants) with a central point (i.e., a conference 
focus), where the focus has direct peer-wise relationships with the 
participants by maintaining a separate SIP dialog with each. 


The focus is a SIP user agent that has abilities to host SIP 
conferences including their creation, maintenance, and manipulation 
using SIP call control means and potentially other non-SIP means. 


In this tightly coupled model, the SIP conference graph is always a 
star. The conference focus maintains the correlation among 
conference’s dialogs internally. 


The conference focus can be implemented either by a participant or by 
a separate application server. 


In the first case, a focus is typically capable of hosting a simple 


ad hoc conference only. We envision that such basic conference can 
be established using SIP call control primitives only. 
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A dedicated conference server, in addition to the basic features, 
offers richer functionality including simultaneous conferences, large 
scalable conferences, reserved conferences, and managed conferences. 
A conferencing server can support any subset of the advanced 
conferencing functions presented in this document. 


The media graph of a SIP conference can be centralized, 
decentralized, or any combination of both, and potentially differ per 
media type. In the centralized case, the media sessions are 
established between the focus and each one of the participants. In 
the de-centralized (i.e., distributed) case, the media graph is a 
(multicast or multi-unicast) mesh among the participants. 
Conseguently, the media processing (e.g., mixing) can be performed 
either by the focus alone or by the participants. 


Conference participants and third parties can have different roles 
and privileges in a certain conference. For example, conferencing 
policy can state that the rights to disconnect from and to invite to 
a conference are limited to the conference chair only. 


Throughout the document, by conference policies we mean a set of 
parameters and rules (e.g., maximum number of participants, needs 
chair-person supervision or not, password protected or not, duration, 
or a way of media mixing) that are defined at the onset of a 
conference. Typically, conference policies would be specified by a 
conference creator and need special privileges to be manipulated. 


Throughout the document, by a conference state we mean a set of 
information describing the conference in progress. This includes 
participants' information (such as dialog identifiers), media 
sessions in progress, the current loudest speaker, the current chair, 
ete: 


3. High-Level Requirements 


In addition to the requirements presented in this document, 
supplementary requirements for conferencing policy, media mixing and 
other manipulations, floor control, privilege control, etc. will be 
discussed in separate documents. 


3.1. Discovery Phase 
Some of the requirements presented in this section can be met either 
by configuration means or by using proprietary conventions. 


Nevertheless, there is consensus that standard means for implementing 
these functions by automata MUST be defined. 
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REQ-1: Discovery of a location of an arbitrary SIP conferencing 
server(s). 


REQ-2: Given a SIP Address-of-Record (AOR) of a certain entity, 
resolution whether the SIP entity has focus capabilities. 


REQ-3: Given a global identifier of a particular conference, locating 
the conference focus. 


REQ-4: Given a global identifier of a particular conference, 
obtaining the conference properties. 


REQ-5: Given a global identifier of a particular conference, 
obtaining the conference state information. 


3.2. Conference Creation 


Given a focus location, a means MUST be defined for an interested 
entity (including a user agent) to implement the procedures below: 


REQ-1: Creation of an ad-hoc conference identifier and the conference 
with specified properties. 


REQ-2: Creation of a reserved conference identifier for a conference 
with specified properties. 


REQ-3: Specifying properties upon conference creation in any of the 
following ways: default, profiles, and explicitly. 


3.3. Conference Termination 


REQ-1: Given a conference identifier, a means MUST be defined for a 
user agent to disconnect all participants from the conference 
and terminate the conference including the release of the 
associated resources. 


REQ-2: A means MAY be defined for requesting a focus to revert a 
two-party conference to a basic SIP point-to-point session 
including the release of the associated conferencing resources. 


3.4. Participants’ Manipulations 


Some of the requirements presented in this section can be met by 
human intervention, configuration means, or proprietary 
conventions. Nevertheless, there is consensus that standard 
means for implementing these functions by automata MUST be 
defined. 
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3.4.1. Participation of a Conference-Unaware User Agent 


REQ-1: Focus MUST be able to invite and disconnect an RFC 3261 
compliant only SIP user agent to and from a SIP conference. 


REQ-2: An RFC 3261 compliant only SIP user agent MUST be able to 
dial-in to a particular SIP conference. In this case, only the 
human knows that he/she is connected to the conference. 


3.4.2. Dial-Out Scenarios 


REQ-1: A means MUST be defined for a focus to invite another user 


agent to one of the focus’ conferences. This procedure MUST 
result in the establishment of a single SIP dialog between the 
two. 


REQ-2: Given an existing SIP dialog between two user agents, if at 
least one user agent has focus capabilities, a means MUST be 
defined for the conference focus to invite the other user agent 
to one of the focus’ conferences without additional SIP dialog 
establishment. 


REQ-3: An invitation to a user agent to join a conference MUST 
include a standard indication that it is a conference and the 
conference identifier. 


3.4.3. Dial-In Scenarios 


REQ-1: A means MUST be defined for a user agent to create an ad hoc 
conference with default properties (as per "Conference Creation" 
REQ-1 above) and to become a participant using a single SIP 
dialog. 


REQ-2: Given a reserved conference identifier, a means MUST be 
defined for a user agent to activate the conference and to 
become a participant using a single SIP dialog. 


REQ-3: Given a conference identifier of an active conference, a means 
MUST be defined for a user agent to dial-in the conference and 
to become a participant using a single SIP dialog between the 
two. 


REQ-4: Given an identifier of one of the dialogs of a particular 


active conference, a means MUST be defined for a user agent to 
dial-in the conference and to become a participant. 
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3.4.4. Third-Party Invitation to a Conference 


REQ-1: Given a conference identifier, a means MUST be defined for a 
user agent to invite another user agent to this conference. 


REQ-2: Given an identifier of one of the dialogs of a particular 
active conference, a means MUST be defined for a user agent to 
invite another user agent to this conference. 


EQ-3: Given a conference identifier, a means SHOULD be defined for a 
user agent to invite a list of user agents to this conference (a 
so-called "mass invitation"). 


3.4.5. Participants’ Removal 


REQ-1: A means MUST be defined for a conference focus to remove a 
conference participant from the conference. 


REQ-2: Given a conference identifier, a means MUST be defined for a 
user agent to remove a participant from the conference. 


REQ-3: Given an identifier of one of the dialogs of a particular 
active conference, a means MUST be defined for a user agent to 
remove a participant from the conference. 


REQ-4: Given a conference identifier, a means MUST be defined for a 
user agent to remove all the participants from the conference. 


REQ-5: Given a conference identifier and a sub-list of participants, 
a means MAY be defined for a user agent to remove the specified 
participants from the conference (a so-called "mass ejection"). 


3.4.6. Participants’ Privacy 


A conference focus SHOULD support the procedures described in this 
section. A conference participant MAY support the procedures 
described in this section. The requirements imply that "anonymizing" 
operations MUST be performed on all: the call control, the media 
control, and the media content when appropriate. 


REQ-1: A conference participant joins the conference "anonymously"; 
that is, his/her presence can be announced but without 


disclosing his/her identity. 


REQ-2: A conference participant requests a focus for anonymous 
participation in the conference. 
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REQ-3: A conference participant joins a conference in a "hidden 
mode"; that is, his/her presence and identity are not to be 
disclosed to other participants. 


REQ-4: A conference participant requests a focus for participation in 
the conference in a hidden mode. 


3.5 Conference State Information 


3.5.1. Description 


By a conference state, we mean a virtual database describing the 
conference in progress. This includes different conference aspects: 
participants’ information (such as dialog identifiers and state), 
media sessions in progress (such as current stream contributing 
sources and encoding schemes), the current loudest speaker, the 
current chair, etc. Conference state is the latest conference 
snapshot triggered by changes in participants’ state, conference 
policy changes, etc. 


REQ-1: A conference state virtual database MUST have a modular 
definition that is, it MUST be possible to access different 
conference aspects independently. 


REQ-2: It MUST be possible to aggregate information relating to 
different conference aspects in a single report. 


REQ-3: A mechanism for extensible definition and registration of 
conference state evolving aspects MUST be present. 


REQ-4: A default conference state report MUST be defined. It SHOULD 
contain a minimal useful set of information (e.g., a list of 
current conference participants). 


3.5.2. Dissemination of Changes 
REQ-1: A means MUST be defined for reporting the conference state 
changes to interested parties (including non-conference 


participants) in a timely manner. 


REQ-2: A means MUST be defined for a SIP user agent to express its 
interest in selected state changes only. 


REQ-3: A means MUST be defined for a SIP user agent to express the 
minimum interval between receiving state change reports. 


REQ-4: It MUST be possible to aggregate recent changes in a single 
reporting event. 
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REQ-5: Default conference state change reports MUST be defined. They 
SHOULD contain minimal useful to the participants information 
(e.g., participants’ joining and leaving the conference). 


3.5.3. On-demand Information Dissemination 


REQ-1: A means MUST be defined to disseminate any conference state 
information to interested parties (including SIP user agents) 
on-demand. 


REQ-2: A means MUST be defined for an interested party (including a 
SIP user agent) to request conference state information of a 
particular conference defined by the conference identifier. 


REQ-3: A means MUST be defined for an interested party (including a 
SIP user agent) to specify the subset of the conference state 
information it wants and is capable of receiving. 


3.6. Focus Role Migration 


REQ-1: A procedure for delegating a focus role by the current focus 
to another participant MUST be defined. 


REQ-2: A procedure for requesting a conference focus to transfer its 
role to another participant MUST be defined. 


REQ-3: A procedure for on-demand unconditional transfer of the focus 
role to a different participant MUST be defined. 


REQ-4: A detection procedure for a focus failure condition MUST be 
defined. 


3.7. Side-bar Conferences 


A standard means MUST be defined in order to implement the operations 
defined in this section below. 


REQ-1: A user agent (not a conference participant) joins a side-bar 
within the conference by SIP means. 


REQ-2: A user agent (not a conference participant) is invited to a 
Side-bar within the conference by SIP means. 


REQ-3: A conference participant creates a side-bar conference with 
one or more participants in a conference by SIP means. 


REO-4: A conference participant joins a side-bar within the 
conference by SIP means. 
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REQ-5: A conference participant is invited to a side-bar within the 
conference by SIP means. 


REQ-6: A conference-unaware user agent (a participant or not) creates 
and participates in side-bar conferences. It MAY be achieved by 
non-SIP means. 


REQ-7: A conference participant creates side-bar conferences within 
the conference without establishing any additional SIP dialogs 
with the focus. It MAY be achieved by non-SIP means. 


REQ-8: A conference participant joins any number of side-bars within 
the conference without establishing any additional SIP dialogs 
with the focus. It MAY be achieved by non-SIP means. 


REQ-9: A conference participant is invited to any number of side-bars 
within the conference without establishing any additional SIP 
dialogs with the focus. It MAY be achieved by non-SIP means. 


3.8. Cascading of Conferences 


"Cascading of Conferences" is a term that has different meanings in 
different contexts. Some examples are listed below: 


= Peer-to-peer chaining of signaling. (Many ways exist to 
build the media graph in this case.) 


= Conferences have hierarchal signaling relations. (Many ways 
exists to build the media graph in this case.) 


= "Cascading" is used to distribute the media "mixing" only. 
The distribution of signaling is not required. 


As it can be seen from the examples, each will define a different set 
of requirements. 


3.9. SIMPLE and SIP Conferencing Coordination 


REQ-1: SIMPLE-based Presence and Instant Messaging architecture 
SHOULD fit into the general SIP Conferencing architecture. 


REQ-2: A scenario where a multimedia SIP conference and a multiparty 
instant messaging conversation take place among the same group 


of participants MUST be addressed. 


REQ-3: A scenario where a side-bar and/or a sub-IM-conference is 
being held as a part of SIP conference MUST be addressed. 
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Security Considerations 


This document discusses high-level reguirements for SIP conferencing. 
Conferencing has some specific security reguirements, which will be 
summarized here at a very high level. 


All of the operations and functions 


to be authorized by a focus or a participant. 


described in this document need 
It is expected that 


conferences will be governed by a set of authorization rules defined 


as a part of the conference policy. 
policy to be implemented, the focus 
potential participants. Normal SIP 
authentication and certificates can 
specific security reguirements will 
protocol documents. 


Conferencing also has privacy implications. 
Standard SIP mechanisms for a user agent 


discussed in this document. 


In order for the conference 
needs to be able to authenticate 
mechanisms including Digest 
be used [2]. These conference- 
be discussed in detail in the 


Some of these are 


to reguest privacy should be utilized by a focus and will be detailed 


in the protocol documents. 
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